desktop/src/renderer/src/lib/components/update/status-copy.ts (1)

19-24: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Missing fallback for undefined version.

UpdateStatus.version is optional per the IPC contract, but statusHeadline interpolates s.version directly for available/downloading/downloaded, which would render as "Version undefined is available" if the field is ever omitted for these states.

💡 Proposed defensive fallback

     case "available":
-      return `Version ${s.version} is available`
+      return `Version ${s.version ?? "unknown"} is available`
     case "downloading":
-      return `Downloading v${s.version} · ${(s.progress?.percent ?? 0).toFixed(0)}%`
+      return `Downloading v${s.version ?? "?"} · ${(s.progress?.percent ?? 0).toFixed(0)}%`
     case "downloaded":
-      return `Version ${s.version} is ready to install`
+      return `Version ${s.version ?? "unknown"} is ready to install`

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@desktop/src/renderer/src/lib/components/update/status-copy.ts` around lines
19 - 24, The statusHeadline logic in status-copy.ts interpolates
UpdateStatus.version directly for the available, downloading, and downloaded
cases, which can surface “undefined” in the UI. Update the statusHeadline switch
to defensively handle missing version values by using a safe fallback or
conditional text for those states, and keep the formatting consistent with the
existing s.progress handling in the downloading branch.

desktop/src/renderer/src/lib/components/update/UpdatesPanel.svelte (2)

1-232: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy lift

Consider adding component tests for UpdatesPanel.

This new component owns non-trivial async logic — downgrade confirmation flow, optimistic channel switch with revert-on-error, and IPC error toasts — none of which appear covered by a dedicated test file (unlike UpdateDialog.test.ts). Given the PR's stated goal of comprehensive update-flow coverage, tests for requestChannel/applyChannel behavior (downgrade vs. upgrade paths, error revert) would guard this critical settings path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@desktop/src/renderer/src/lib/components/update/UpdatesPanel.svelte` around
lines 1 - 232, Add a dedicated test file for UpdatesPanel to cover its async
channel-switch flow and IPC error handling. Focus on the requestChannel and
applyChannel paths: verify downgrade selections open ConfirmDialog instead of
switching immediately, verify normal upgrades call setReleaseChannelIpc and show
success toasts, and verify failures revert releaseChannel and emit the error
toast. Use the existing component behavior around markUserInitiated,
getReleaseChannel, and channelLabel to locate the logic under test.

---

168-189: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add ARIA semantics to the channel picker.

The channel cards act as an exclusive-choice control but expose no role/aria-checked state, so screen readers can't tell which channel is selected (only a visual border + checkmark indicate it).

♿ Proposed fix

-    <div class="grid grid-cols-2 gap-3">
+    <div class="grid grid-cols-2 gap-3" role="radiogroup" aria-label="Release Channel">
       {`#each` CHANNELS as c (c.value)}
         <button
+          type="button"
+          role="radio"
+          aria-checked={releaseChannel === c.value}
           class="rounded-lg border p-3 text-left transition-colors {releaseChannel === c.value
             ? 'border-primary bg-primary/5 ring-1 ring-primary'
             : 'border-border hover:border-muted-foreground/50'}"
           onclick={() => requestChannel(c.value)}
         >

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@desktop/src/renderer/src/lib/components/update/UpdatesPanel.svelte` around
lines 168 - 189, The channel picker buttons in UpdatesPanel.svelte are visually
exclusive but չուն’t expose selection state to assistive tech. Update the button
group rendered from CHANNELS to use proper ARIA semantics for a single-select
control, and add the selected state on each option based on releaseChannel ===
c.value. Keep the existing requestChannel(c.value) behavior, but make each card
announce its role and checked/selected status consistently with the current
visual state.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

desktop/src/renderer/src/lib/components/update/UpdatesPanel.test.ts (1)

85-94: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Downgrade confirmation flow isn't tested end-to-end.

This test only checks that the confirm dialog appears and setReleaseChannel hasn't fired yet. There's no coverage for clicking through the confirmation (verifying setReleaseChannel("stable") eventually fires) or canceling it (verifying the selection stays on Preview and no IPC call is made). Given the PR explicitly calls out downgrade-confirm as a reviewed path, closing this gap would meaningfully raise confidence in the new confirmation UX.

Suggested additional coverage

   it("opens a confirmation instead of switching on a downgrade", async () => {
     await renderPanel("beta")

     cardButton(/Stable/)?.click()
     await tick()

     // Downgrade must wait for confirmation — no IPC call yet.
     expect(setReleaseChannel).not.toHaveBeenCalled()
     expect(document.body.textContent).toMatch(/switch to the stable channel\?/i)
   })
+
+  it("confirms and switches on downgrade confirmation", async () => {
+    await renderPanel("beta")
+    cardButton(/Stable/)?.click()
+    await tick()
+
+    // Click through the confirmation button (adjust selector to match component).
+    const confirmBtn = Array.from(document.querySelectorAll("button")).find((b) =>
+      /confirm/i.test(b.textContent ?? ""),
+    )
+    confirmBtn?.click()
+    await tick()
+    await Promise.resolve()
+
+    expect(setReleaseChannel).toHaveBeenCalledWith("stable")
+  })
+
+  it("cancels the downgrade confirmation without switching", async () => {
+    await renderPanel("beta")
+    cardButton(/Stable/)?.click()
+    await tick()
+
+    const cancelBtn = Array.from(document.querySelectorAll("button")).find((b) =>
+      /cancel/i.test(b.textContent ?? ""),
+    )
+    cancelBtn?.click()
+    await tick()
+
+    expect(setReleaseChannel).not.toHaveBeenCalled()
+    expect(cardButton(/Preview/)?.getAttribute("aria-checked")).toBe("true")
+  })

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@desktop/src/renderer/src/lib/components/update/UpdatesPanel.test.ts` around
lines 85 - 94, The downgrade confirmation path in UpdatesPanel is only partially
covered by the existing test in UpdatesPanel.test.ts. Extend the test around
renderPanel, cardButton, and setReleaseChannel to cover the full confirmation
flow: one case should click through the dialog and assert
setReleaseChannel("stable") is eventually called, and another should cancel the
dialog and assert the selected channel remains Preview with no IPC call. Keep
the coverage anchored to the same confirmation UI text and release channel
switching behavior.